我們終於來到 BeyondCorp 系列文獻目前的最後一篇：BeyondCorp and the long tail of Zero Trust: Handling the most challenging use cases at Google。本篇著於 2023/06/05，超級新，旨在說明 Google 是如何處理那些難以遷移至 BeyondCorp 架構的應用程式（也即"長尾")，他們的解決方案、策略以及經驗教訓。

其中有很多內容在 "Day 15 遷移到 BeyondCorp——成功導向的遷移（續）" 中有提到過，這篇算作一個經驗總結和方法論。

BeyondCorp 架構下的困難用例

先前的 BeyondCorp 系列文章討論了 Google 是如何將內部所有應用程序從 Managed Privileged Client (MPC) 遷移到 Managed Non-Privileged (MNP) 網路。Migrating to BeyondCorp: Maintaining Productivity While Improving Security 說明了針對主要的應用程序進行遷移的流程、工具和解決方案。

但不是所有應用程序都可以順利地遷移。特別是有些應用程序無法與 Access Proxy 兼容。例如具有下列特徵的第三方應用程序就無法兼容 Access Proxy:

• 雖然是基於 HTTPS，但無法爲 Access Proxy 提供憑證
• 需要使用非 HTTPS protocols 與各種後端建立 IP 層連接
• 需要基於 IP 的客戶端白名單才能正常運行

儘管這些應用程序擁有相當數量的用戶，但這些應用程序在內部是不受官方支持的，他們能 "意外地" 無縫運行不過是因爲 Managed Privilege Client (MPC) 授予他們過寬的訪問權限。

即使是對於那些與 Access Proxy 兼容的應用程序，Access Proxy 也會對那些具有嚴格的帶寬或延遲要求的團隊構成挑戰。因爲與直接訪問本地服務器相比，通過 Access Proxy 進行訪問可能會降低性能，特別是如果該 Proxy 與用戶的物理距離較遠時。

這些問題工作流程有很多都是透過先前提到過的在設備上安裝的 MNP simulator 識別出來的。相關用戶被授予例外權限可以暫時停留在 Managed Privileged Client (MPC) 網路中，直到我們找到解決方案。其中包含了很多關鍵業務，例如財務或物理安全 (physical security)，而後被認知爲 BeyondCorp 架構的 "長尾"。

經驗教訓：

• 當環境存在特權時，我們預期用戶和系統會對其產生依賴。
• BeyondCorp 架構下的長尾（那些困難用例）可能跨足多個分佈式組織，以至於沒有單一的管理層可以獨自推動長尾的成功遷移。

今天先到這裡。終於來到最後一篇了，心情還是很激動的。「不知不覺地就快要看完了系列文獻呢！」今天突然就有這樣的感慨。不過鐵人賽估計是講不到 Identity Aware Proxy 了，也沒辦法講到 BeyondCorp Enterprise，殘念啊。。。不過學海無涯，到時候換棚繼續鐵人馬拉松也不是不行哈哈（人要挺得住才是真的）想做的事很多，只能一點一點慢慢做，慢慢來就會很快。繼續加油吧~

明天見！